“Status icons” go by a few different names. A lot of people know them by the area where they appear, which gets described as the “system tray” or “notification area”. Whatever you call it, it’s the place where a string of little icons often gets shown, typically by applications that are running in the background.
GNOME 3 currently shows status icons in the bottom-left corner of the screen, in a tray that slides in and out. We know that this isn’t a good solution. The tray gets in the way and it generally feels quite awkward. There’s a general consensus that we don’t want to continue with this UI for the upcoming version of GNOME 3.
At the same time, the GNOME project has done a lot of work in recent years that reduces the importance of status icons. This includes integrating media controls and weather information into the shell’s calendar drop down, creating the Night Light, and working with third party application developers to reduce their reliance on status icons. In the next release, we will be introducing a new integration API for file synchronisation apps, which will be another positive step.
From GNOME 3.26, we are therefore planning not to show status icons in GNOME Shell by default. We feel that, long-term, this change will enable us to provide a better experience for our users (I’ll go into some detail about this in the rest of the post). We also feel that the consequences of the change won’t be as dramatic as they would have been in the past.
We do recognise that people are using status icons today and that some will continue to want to use them. That’s absolutely fine, and our decision to stop showing status icons by default is in no way a negative judgement on this. If you want or need to continue using status icons, you should feel free to use the TopIcons GNOME Shell extension. This will continue to work and the extension offers a better status icon experience than the current default anyway.
We will, of course, continue to monitor the situation, and will be listening to feedback. There is also a full set of information about the change on the GNOME wiki, including an FAQ and guidelines for application developers.
Advice for application developers
Having reviewed how applications are using status icons, we are confident that the majority of applications that use status icons will not be impacted by the decision not to display them by default. In many cases applications won’t have to make any changes, and if changes are required we have hopefully contacted you already.
It is also worth noting that many of the recommendations for how to provide a good experience without status icons are established guidelines anyway, and can be adopted whether an application is using a status icon or not (such as using existing APIs effectively and having a consistent behaviour when your application is launched). This is a great opportunity to improve applications more generally!
If you are an application developer and are uncertain about whether this change affects you, or how to adjust to it, check out the guidelines on the GNOME wiki and feel free to get in touch if you are still uncertain. We want to help you any way we can.
The rest of this post includes background information on our approach to status icons. It will hopefully help those who are interested to understand the decision a little better.
The why.
Still with me? OK, let’s continue!
As a starting point, it’s worth pointing out that status icons are pretty old. The first version of the spec is dated April 2002, which means that it predated GNOME 2.0. They had “balloon messages”. It perhaps goes without saying, but status icons are something that we inherited, rather than something that was designed as part of the overall experience.
But why don’t we want them anymore? There are some specific issues with status icons, which I’ll get on to, but the main reasons relate to a) the existence of better APIs and b) how they align with GNOME’s wider design philosophy and goals. The following are some of these.
1. Purposeful API
In GNOME we have two closely related goals: to provide application developers with a clear vision of how apps should be built and to provide users with a simple, easy to understand and logical experience. One key ingredient to achieving this is to have a straightforward set of APIs for application integration.
We want to have clearly differentiated APIs, with each one having its own role. Primary examples include:
- Notifications for informing users about events
- MPRIS for media playback
- Search providers for integrating with system search
- libcloudproviders for providing integrated file sync services
Status icons originated prior to all of these, and overlap with three of the four. This creates ambiguity for developers and makes it harder to know which APIs to use. Should you use notifications to notify users, or status icons? Is it best to use a status icon or MPRIS for media controls? While some of these questions can be answered by documentation and guidelines, there’s no avoiding the fact that they generate ambiguity and, inevitably, inconsistent application behaviour. Many applications today use status icons as a notifications system, despite the existence of the official notifications API, for example.
2. Application versus system
One of GNOME 3’s central design tenets is to clearly differentiate system and applications. This is intended to make the structure of the experience clear to users. It is one reason why we call the area in the top right the system status area.
Status icons and system status are both concerned with status and there is therefore a natural pull to merge the two (indeed, back in the GNOME 2 days, status icons were used for both application and system status). This is how status icons are typically presented on other platforms. However, we feel that this would dilute the experience as a whole, since it would introduce a lack of clarity over what belongs to what. The influence of this kind of distinction is a subtle but pervasive one.
3. User control
Another key design principle for GNOME is to put the user in control. We aim to ensure that how the system looks and behaves is determined by the user. The only person who should be able to change your wallpaper, your preferred wi-fi networks, your favourite applications or your default email client, is you. This is one reason why we are so keen on the concept of application sandboxing.
The design of status icons goes against this principle. We know from observation that people often only care about a small fraction of the status icons that they are exposed to, and the rest don’t reflect their interests or activities. This stems from the status icon API and the ethos behind it.
Users don’t opt into status icons. They don’t neatly stay out of the way when they’re not wanted (as with notifications). They don’t reflect a particular type of user activity (like MPRIS integration). In essence, they take control from the user.
4. Accessible click targets
Finally, throughout GNOME 3, we have attempted to ensure that click targets are always easy to target. Teeny tiny click targets pose a challenge in a whole host of situations, from those with poor quality pointing devices, to those who don’t have the same level of motor control as others. Look around and you won’t see many small click targets in GNOME 3, and this is why.
This goal was one of the motivations for the combined system status area that we introduced back in GNOME 3.10. It is why those standalone top bar items that we have retained have been made a little wider, with the addition of disclosure triangles.
Status icons are, in essence, a string of tiny little click targets. They are hard to click.
Scalability
Clearly differentiated API, a distinction between applications and system, ensuring user control and keeping our UI accessible are four design principles which inform our view on status icons.
Another reason for wanting to move away from status icons is more a criticism of the concept itself. Part of the difficulty with status icons is just how appealing they are to application authors. They are visually prominent, giving great advertising and brand presence. They also provide users with quick access to application controls. What’s not to like!?
Unfortunately the very attractiveness of status icons leads to problems. Most obviously, users often end up with too many of them.
Every platform that has embraced status icons has ended up having to wrestle with this problem, from the Windows notification area overflow, merging of application indicators on Ubuntu, and a raft of modifications on Mac. In my mind, all of these management solutions are indicative of an underlying issue.
There’s a contradiction at the heart of a system which on the one hand offers to present application UI in a persistent manner, but which can be used by any number of applications. In the end, you end up presenting more information than users can process. When this happens, some of the icons have to be hidden, which means going back on the central promise of persistent presence. The whole concept eventually collapses.
Conclusion
We recognise that this is a potentially contentious issue. At the same time, we hope that this post has helped to provide some better insight into why the decision has been made and shows how it is part of a more general effort to improve the platform.
My feeling is that we have actually been using status icons as a crutch for far too long – that they have been used to fill gaps in our APIs, gaps which are now thankfully getting filled – and that moving away from them will help us to extend application integration in some exciting directions.
Finally, when we say that we want to hear feedback we truly mean it: there are bound to be issues that need addressing and that we need to hear about. The more information we have, the better.